Note that this won't fix loops completely. break statements inside of loops (outside of a switch) are ignored completely so an always true loop is unrolled up to maxIterations.

However this PR doesn't introduce this problem. It was already a problem before this pull request for conditions always evaluating to true in while/for loops.

unfortunately, I soon realized that developing a plugin capable of reconstructing the entire control flow is almost impossible, if not definitely impossible. My first idea was to make the deobfuscator purely static and provide examples where a control flow flattening is reconstructed. I noticed that using a VM generates a lot of potential errors. I would appreciate it if you could tell me your opinions regarding these topics.

@lorenzoferre I agree... My use-case is just to reconstruct the control flow of Hermes binaries decompiled with https://github.com/P1sec/hermes-dec

Basically Hermes maps really well to the original JavaScript except that it converts conditions and loops to jumps and conditional jumps. Since true gotos don't exist in JavaScript hermes-dec simulates them with while (true) loops + adhoc switches (where each case: corresponds to the label of a goto). Every time the Hermes code does a jump it instead puts the destination label in a variable i.e. label and then does the equivalent of a continue to come back to the beginning of the loop, which at the top level has a switch(label) that makes it jump to e.g. case 123: if the original goto pointed to label 123.

I was kind of lazy so my plan was to piggyback on someone's JavaScript deobfuscator (because I know that control flow flattening is a usual obfuscation technique) to restore the control flow.

But since I couldn't find a working implem I guess I will need to do it on my own. This is a bit tricky because the only way I see to solve it would be to represent the gotos and labels as a graph so I can find the cycles (which correspond to loops) and the directed acyclic subgraphs (which correspond to conditions).

@devnoname120 I'm currently studying these topics, but I haven't found a solution yet. Is it possible to solve control flow flattening statically by only constructing the control flow graph? Once you have a control flow graph, what operation should you perform? The first thing that comes to my mind is to check whether the cases within the switch blocks contain conditions that use the dispatcher variable (label), for example, "if label < 7, do something; otherwise, do something else." In that case, I think you have to create a vm context and include the variable label. The drawback is that if there are variables that influence the variable label, you have to include them in the context as well.
However, if you are familiar with the static manipulation of control flow graphs, I would really appreciate it if you could share your knowledge with me